1. Field of the Invention
The invention relates to client server communications. Specifically, the invention relates to apparatus, systems, and methods for automatically freeing a server resource locked awaiting a failed acknowledgement from a client.
2. Description of the Related Art
Client-server communications characterize a large part of the inter-process communication in today's computer systems and networks. In particular, database servers provide database data and results to a plurality of clients. The database servers often support a plurality of protocols and connect to clients over a variety of networks. However, the expected performance of the database server remains the same.
Certain database servers, such as IBM's Information Management System (IMS), are expected to maintain high performance expectations due to the nature of the data managed in the database. The performance expectations remain high regardless of the quality of the network connection and/or protocol between the client and the server or the capabilities of the client. Furthermore, such database servers are expected to service large volumes of transactions almost simultaneously. Transactions need to be completed as quickly as possible. The database servers are required to operate 24/7 with any down time kept to an absolute minimum. Large corporations and other entities invest heavily in the speed, reliability, and security provided by such database servers.
Data maintained by the database servers is often very critical to the owner of the data and/or the user. The data may comprise financial data, sales transaction data, and the like. Consequently, certain transactions between the client and server can be mission critical, meaning the client and server are to cooperate to ensure that all messages exchanged are properly received by the receiver (client/server). To ensure proper receipt of a message, the communication protocol generally requires that the receiver provide an acknowledgement (ACK) message to the sender. The ACK message confirms that the last message sent by the sender was properly received by the receiver.
FIG. 1 illustrates a conventional system 100 in which an ACK message is to be sent. The system 100 includes a client 102, a network 104, and a server 106. The server 106 is a combination of hardware and/or software executing various operating systems, such as Multiple Virtual Storage (MVS), OS/390, zSeries/Operating System (z/OS), UNIX, Linux, and the like.
The client 102 may comprise a web-based client, a middleware software module, a gateway application, or any other software module configured to communicate directly with the server 106. Representative examples of clients 102 include Tivoli®, DB2®, MQseries®, IMS connect, and the like. FIG. 1 illustrates that the client 102 may communicate with end-user “clients 102.” For clarity, references hereinafter to a “client 102” refer to any software application configured to communicate directly with the server 106.
Generally, the client 102 initiates a communication session with the server 106 by sending a request 108 over the network 104. The network 104 may comprise direct terminal connections, a Local Area Network (LAN), Wide Area Network (WAN), the Internet, or the like. Typically, the client 102 establishes a connection to the server 106 prior to sending the request 108. The request 108 initiates a transaction. A transaction may include the exchange of a plurality of messages until sufficient operations are completed such that the transaction can be successfully ended. Furthermore, the client 102 can typically identify mission critical transactions for the server 106 to complete. Accordingly, a network communication protocol, such as Transmission Control Protocol/Internet Protocol (TCP/IP) or the like, requires that the server 106 retain results of a transaction until the client 102 provides an ACK message indicating that the result message was properly received and uncorrupted. Other types of transactions may not require an ACK message from the client 102.
In FIG. 1, the client 102 sends a request 108 to the network 104 which relays the request 108 to the server 106. The server 106 performs the operations indicated in the request 108 and sends a response 110 to the network 104. Typically, between a client 102 and a database server 106, the response 110 comprises results of a database transaction. Once the response 110 is sent, the server 106 waits for an ACK message 112 from the client 102.
Because the transaction is mission critical, the server 106 reserves or locks certain server resources 114 until the ACK message 112 is received. Typically, the server resources 114 are the resources of the server required to reproduce the results. Examples of certain server resources 114 may include memory sections, buffers, communication channels/sockets, record/table locks, and the like.
Unfortunately, the server 106 does not always receive the ACK message 112. In some cases, the client 102 may send an ACK message 112 to the network 104, but some intermediate node (not shown) in the network 104 may fail to relay the ACK message 112. Certain types of networks 104, such as a TCP/IP network, may be more prone to such a problem. In other cases, the client 102 may erroneously fail to transmit an ACK message 112.
In either case, the result is the same. The server 106 has locked certain resources 114 in anticipation of an ACK message 112 that will never arrive. Conventionally, the locked resources 114 must be freed manually by a server administrator interacting with the server 106.
The server 106 has a finite number of the resources 114. Consequently, as additional transactions are serviced that indefinitely lock additional resources 114, all the resources 114 inevitably become locked. The server 106 is then unable to accept any new transactions or may go off-line.
From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method that automatically free a server resource locked awaiting a failed acknowledgement from a client. Beneficially, such an apparatus, system, and method would free the server resource in response to a timeout value that corresponds to current delays in communications between the client and the server. In addition, the apparatus, system, and method would allow such a timeout value to be extended by a default value, a server level value, a connection level value, or a transaction level value. In addition, such an apparatus, system, and method would provide notification that an ACK message was not received and queue the unacknowledged message for subsequent delivery after the server resources are freed.